The present invention relates generally to testing, and more particularly to a method and apparatus for verifying multiprocessing design in a unit simulation environment.
In order to achieve large amounts of processing bandwidth, multiple processors are often combined in a single system such that parallel-processing operations can occur. In such systems, the multiple processing entities often share a single memory structure that is accessed via a common bus. Another feature that increases the processing capabilities of such multiprocessing systems is the inclusion of one or more cache structures in one or more of the processing entities. High performance processing systems often include more than one cache structure in each processing entity.
Because of the shared memory structure and the inclusion of the cache structures within the processing entities, data integrity, which is crucial to proper system operation, becomes an issue that must be addressed. In one example, data integrity may be compromised in such systems if the data corresponding to a particular memory address is cached in a modified form in one of the processing entities, and another processing entity which desires to utilize the same data retrieves it from memory without notification that an updated version of the data is present in the cache structure of the other processing entity. Although various parameters are included in the caching structures to indicate the various potential states of cached data, the interaction between the multiple processors requires constant monitoring and maintenance of these parameters in order to ensure data integrity.
In prior art systems that include multiple processors, verification of the logic that controls the interactions that assist in maintaining data integrity was not adequately verified until late in the design process. The reason for the late occurrence of verification of the multiprocessing portion of the system design was often due to the need for verification of the other functional blocks within each of the processors prior to verification of the multiprocessing logic. For example, the sequencer that operates on the instructions and the execution units that perform operations on instructions had to be verified in order to allow instruction-based test programs to be executed. Verification of the multiprocessing logic at the system, or chip level, is difficult as the chip model is complex, and therefore execution of test sequences at this level is slow and often does not provide optimal exercising of the multiprocessing portions of the system intended to be verified.
In some prior art systems, transaction-based verification of the multiprocessing blocks is performed at the unit level where the multiprocessing logic is isolated and specifically targeted by the testing. Transaction-based verification applies specific transactions, or signal stimulus sets, at an interface between the multiprocessing block and the other blocks in the processing system. The interface can then be monitored to determine if the proper transactional response occurs.
One drawback of transaction-based testing is that the transaction-based tests are often deterministic tests that were compiled for particular scenarios and required an understanding of the expected results. Random test generation is typically only possible if a behavioral model of the multiprocessing portion of the processor is available to generate expected results. Because the behavioral model must accurately model the operation of the multiprocessing logic as designed, any change to the logic within the multiprocessing portion of the processor requires similar modification to the behavioral model. Maintenance of the behavioral model requires diligence and presents the potential of modeling errors, both of which make random transaction-based tests undesirable.
Another drawback of transactional testing is that as the integration of the multiprocessing portion with other blocks in the processing module occurs during the design process, the transactional tests used to exercise the multiprocessing portion cannot be reused at higher levels of integration. This is because the transactional tests are designed to provide stimulus to a particular interface to the multiprocessing block. This stimulus does not exercise any other portions of the system, and therefore do not provide any benefit at subsequent integration levels. As such, new test sequences must be created in order to properly exercise the design at higher levels of integration.
Therefore, a need exists for a method and apparatus that allows for verification of multiprocessing functionality in a manner that permits instruction-based test sequences to be utilized to exercise the multiprocessing portions of the system at a unit level in a manner that is efficient and exercises this portion of the system at a high rate of speed.